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Description 
Field of invention 

[0001] The present invention is related to voice over s 
IP communication systems, and more particularly, to a 
method and system of providing IP-based enhanced 
emergency services using intelligent client devices. 

Background to the invention w 

[0002] Enhanced emergency services for telephony 
systems tie the caller's physical location to the call sig- 
naling and follow-on messaging. The goal is to increase 
the effectiveness of the emergency response person- is 
nel. By helping pin-point the caller's location, as well as 
adding reliability to the telephony link between the caller 
and the emergency responder, precious time may be 
saved in responding to an emergency. In the United 
States, the service is referred to as E-91 1 . 20 
[0003] While government and industry groups have 
worked together to provide consistent requirements of 
the E-911 system, many aspects of practical implemen- 
tations have not yet achieved standardization. The va- 
riety of systems currently deployed may share common 25 
elements in their respective designs, but optimal solu- 
tions are still lacking for many of the technical challeng- 
es posed by the requirements. This is particularly true 
for an IP telephony system in an enterprise or campus 
environment. 30 
[0004] The successful delivery of E-911 service re- 
quires that two general areas of operation be satisfied: 
1) the ability to route 911 calls to an appropriate emer- 
gency response center, based upon the location of the 
caller (calling station); and 2) the ability of the emergen- 35 
cy response center to both locate, and automatically call 
back to, the calling station, following the receipt of a 91 1 
call from that station (call-back being required, e.g., in 
the event that the original call gets disconnected). Both 
of these are related to each other by virtue of their de- 40 
pendency on the location of the calling station. There- 
fore, accurate and verifiable location of the caller is fun- 
damental to proper implementation of E-911 service. 

1 . Emergency E91 1 Terminology 45 

[0005] The definitions below reproduce E-911 termi- 
nology listed at the Association of Public-Safety Com- 
munication Officials (APCO) website. The list may be 
accessed at the following Internet website at www. so 
apco911.org/about/pbx/index.html: 

9-1-1: A three digit telephone number to facilitate 
the reporting of an emergency requiring response 
by a public safety agency. ss 
9-1-1 Service Area: The geographic area that has 
been granted authority by a state or local govern- 
mental body to provide 9-1-1 service. 


9-1-1 Service Provider: An entity providing one or 
more of the following 9-1-1 elements: network, 
CPE. or database service. 
9-1-1 Tandem: (See E9-1-1 Control Office) 
Access Line: The connection between a customer 
premises network interface and the Local Ex- 
change Carrier that provides access to the Public 
Switched Telephone Network (PSTN). 
Automatic Location identification (ALf): The auto- 
matic display at the PSAP of the caller's telephone 
number, the address/location of the telephone and 
supplementary emergency services information. 
Automatic Location identification (ALl) Database: 
The set of ALl records residing on a computer sys- 
tem. 

Automatic Number identification (ANl): Telephone 
number associated with the access line from which 
a call originates 

Centrai Office (C >:The Local Exchange Carrierfa- 
cillty where ace . : lines are connected to switching 
equipment for connection to the Public Switched 
Telephone Network. 

Centralized Automated Message Accounting (CA- 
MA): An MF signaling protocol originally designed 
for billing purposes, capable of transmitting a single 
telephone number. 

Data Base Management System Provider: Entity 
providing Selective Routing (SR) and/or Automatic 
Location identification (ALl) data services. 
Data Provider: An entity which provides, on a rou- 
tinely maintained static database, names, address- 
es and telephone number to be inserted and updat- 
ed in the E911 MSAG. Data providers are defined 
as local exchange carriers, alternate exchange car- 
riers, wireless carriers or an entity authorized to act 
on behalf of any of the aforementioned entities. 
Default Routing:The capability to route a 9-1-1 call 
to a designated (default) PSAP when the incoming 
9-1 -1 call cannot be selectively routed due to an AN I 
failure or other cause. 

Enhanced 9-1-1 (E9-1-1) Controt Office; The Cen- 
tral Office that provides the tandem switching of 
9-1-1 calls. It controls delivery of the voice call with 
ANl to the PSAP and provides Selective Routing, 
Speed Calling, Selective Transfer, Fixed Transfer, 
and certain maintenance functions for each PSAP. 
Also known as 9-1-1 Selective Routing Tandem or 
Selective Router. 

Emergency Location identification Number (ELIN): 
A valid North American Numbering Plan format tel- 
ephone number assigned to the MLTS Operator by 
the appropriate authority that is used to route the 
call to a PSAP and is used to retrieve the ALl for the 
PSAP. The ELIN may be the same number as the 
ANl. The North American Numbering Plan number 
may in some cases not be a dialable number. 
Emergency Response Location (ERL): A location 
to which a 9-1 -1 emergency response team may be 
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dispatched. The location should be specific enough 
to provide a reasonable opportunity for the emer- 
gency response team to quickly locate a caller an- 
ywhere within it. 

Emergency Service Number {ESN): A number as- 
signed to specific geographic area within which all 
E91 1 calls are routed to one specific PSAP and the 
residents of the area are served by the same police, 
fire, and emergency medical agencies. 
Emergency Service Zone (ESZ): The geographic 
area within which all E911 calls are routed to one 
specific PSAP and the residents of the area are 
served by the same police, fire, and emergency 
medical agencies. 
Fast Busy: (see Reorder Tone) 
Grade of Service:Jhe probability (P), expressed as 
a decimal fraction, of a telephone call being 
blocked. P.01 is the grade of service reflecting the 
probability that one call out of one hundred during 
the average busy hour will be blocked. P.01 is the 
minimum recommended Grade of Service for 9-1-1 
trunk groups. 

Master Street Address Guide (MSAG): A data base 
of street names and house number ranges within 
their associated communities defining Emergency 
Service Zones (ESZs) and their associated Emer- 
gency Service Numbers (ESNs) to enable proper 
routing of 9-1-1 calls. 

No Record Found (NRF): A condition where no ALI 
information is available for display at the PSAP. 
P.01 Grade of Service: (See Grade of Service.) 
PBX: (See Private Switch) 
Primary Public Safety Answering Point (PSAP): A 
PSAP to which 9-1-1 calls are routed directly from 
the 9-1 -1 Control Office. (See PSAP) 
Primary Rate interface (PRI): Primary Rate Inter- 
face (PR!) is trunking technology which enables the 
networking of multiple locations. A single PRI trunk 
can carry various types of traffic. PRI provides such 
features as Calling Number Delivery, Called 
Number delivery, Network Redirection and Reason, 
Network Name, Network Ring Again, Network Au- 
tomatic Call Distribution, Equal Access, Special 
number Services, integrated Service Access (ISA), 
Network Message service, and Release Link Trunk 
(RLT). Each PRI trunk group requires one D-Chan- 
nel and can support multiple DS-1 s up to a maxi- 
mum of 479 B-channels distributed over 20 DS-1 
links. PRI call processing supports Q.931 messag- 
es for call setup, call progress, and feature activa- 
tion. 

Private Switch ALI (PS/AU): A service option which 
provides Enhanced 9-1-1 features for telephone 
stations behind private switches, e.g. PBXs 
Public Safety Answering Point (PSAP): A facility 
equipped and staffed to receive 9-1-1 calls. A Pri- 
mary PSAP receives the calls directly. If the call is 
relayed or transferred, the next receiving PSAP is 


designated a Secondary PSAP. 
Public Switched Telephone Network (PSTN): The 
network of equipment, lines, and controls assem- 
bled to establish communication paths between 

5 calling and called parties in North America. 

Reorder Tone: An audible tone of 120 interrupts per 
minute (ipm) returned to the calling party to indicate 
the call cannot be processed through the network. 
Sometimes referred to as fast busy. 

10 SCC: The Qwest 9-1-1 database management 
service provider. 

Selective Routing (SR): The routing of a 9-1-1 call 
to the proper PSAP based upon the location of the 
caller. Selective routing is controlled by the ESN 

15 which is derived from the customer location, 

System Integrator: Coordination and oversight re- 
sponsibilities as undertaken by the Company relat- 
ing to the quality of 911 serviced provided by the 
Company, alternate exchange carriers and data 

20 providers. 

2. E-911 Service Requirements 

[0006] The primary elements of E-91 1 service are: 1 ) 

25 association of locations with 911 calls; and 2) routing 
911 calls to emergency response centers most suited to 
answering and responding (including dispatching emer- 
gency personnel) to specific calls. The emergency re- 
sponse center is referred to as the Public Safety An- 

30 swering Point, or PSAP. The mechanisms of E-91 1 serv- 
ice include transport of vital and relevant information in 
the call signaling, using this information to route the call 
to the optimal PSAP, and presenting this information to 
the PSAP personnel to help determine the location of 

35 the caller. 

[0007] When a 911 call is placed, the location of the 
caller is used to route the call to an appropriate end- 
office switch. The calling station location is referred to 
as the Emergency Response Location, or ERL The 

40 routing can be static, e.g., as in the case of a residential 
connection to a specific end-office; or dynamic, e.g., as 
in the case of a lookup by a PBX system based upon 
the calling station extension, included in the call signal- 
ing is a phone number called the Emergency Location 

45 identification Number, or ELIN, that identifies the ERL 
from which the call was placed. The ELIN is included in 
the call signaling of a 911 call as the ANI. In the PSTN, 
the ELIN is used to route the call to an appropriate 
PSAP. The routing is done by accessing a location in- 

so formation database called the called Automatic Location 
identification (ALI) Database. The ELIN may also be 
used by the responding PSAP to access the ALI for de- 
tailed location information. The PSAP may also use the 
ELIN to call back the calling station in the event that the 

55 call gets disconnected. 

[0008] in addition to the procedures used to set up a 
911 call and determine the location of the caller, the sys- 
tem must insure that emergency calls cannot be disrupt- 
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ed by signaling events which might be aliowablefor non- 
emergency calls. For example, if the caller has call-wait- 
ing service, it must be disabled during an emergency 
call from that caller's phone. Similarly, only the PSAP, 
or its representative, may release a 911 call; if the caller s 
hangs up the phone during a 911 call, the call should 
not be released. Other potentially interrupting service 
features must similarly be disabled. The PSTN typically 
provides these capabilities. 

[0009] Typically in a PBX system, an on-site emer- 10 
gency facility will be notified when a 911 call is placed. 
This may be a simple logging system, or a security sys- 
tem that is monitored by security/safety personnel. The 
information available to such a system may include 
more detail than that passed to the PSTN , or maintained 
in the ALI database. For example, the location informa- 
tion available to the on-site system may be precise 
enough to identify an office or cubicle, while the ERL 
available to the PSAP may only identify a building floor 
or wing. Reliance on an on-site component to a PBX 
emergency response system is one approach to mitigat- 
ing some of the difficulties in designing such a system. 
[0010] Deployment of E-911 behind a PBX introduces 
further considerations such as location precision, map- 
ping ELIN to calling station, and the information in the 
ALI database; As noted, the specification of the location 
of a 911 calling station is defined as the Emergency Re- 
sponse Location, or ERL. The precision with which the 
ERL actually locates a calling station may vary. For ex- 
ample, for residential service, an ERL may be the ad- 
dress of a house, or a unit within an apartment complex. 
For an enterprise PBX, an ERL could be a building ad- 
dress, a floor in building, a wing on a floor, or even an 
office or cubical. 

[001 1 ] When an ERL corresponds to an extended ar- 
ea, such as building floor or wing, it may contain multiple 
calling stations. Note that the information used both to 
route a 911 call to a PSAP, as well as to provide the 
PSAP with the location of the calling station, is only as 
precise as the ERL from which the call is placed. Con- 
siderations in specifying an ERL can include state and 
local regulations governing required precision of the lo- 
cation, and, in the case of multi-station ERLs, the max- 
imum number of calling stations that a single ERL may 
contain. Recall that the Identity of an ERL is associated 
with the ELIN, which acts as a phone number. Note that 
one ERL may possess more than one ELIN, but one 
ELIN may identify one and only one ERL. 
[0012] Within the PSTN, location information is main- 
tained m a database called the Automatic Location Iden- 
tification (ALI) Database. Typically, there are multiple 
ALI daiabases, each associated with, e.g., a different 
calling area, or different local exchange carrier (LEC). 
The ALI database essentially correlates ELINs with ER- 
Ls, as well as with routing rules for directing 911 calls to 
appropriate PSAPs. Thus the ALI database is queried 
using the ELIN when a 911 call is made to determine 
which one of possibly multiple PSAPs should receive 


the call. One/? the call is received by the PSAP, the ELIN 
may again : jsed to query the ALI, this time to provide 
ERL inforrr on. The ELIN can also be used by the 
PSAP as a direct call back numberto the calling station, 
e.g., in the event that the original call is disconnected. 
That is, as far as the PSAP is concerned, the ELIN func- 
tions as a Direct inward Dial (DID) number to the calling 
station. Note that in the case of multi-station ERLs, a 
single ELIN may be shared among all calling stations in 
an ERL. Therefore, in order for the PSAP to be able to 
use the ELIN as a DID numberto refer to a specific call- 
ing station, some form of mapping from ELIN to calling 
station must be implemented by the PBX. 
[0013] When a 911 call is placed from behind a PBX, 
the ERL of the calling station is the factor that deter- 
mines the ELIN that will be passed to the end-office 
switch; i.e., into the PSTN signaling space. Before the 
call is actually passed to the PSTN, the PBX, or some 
associated on-site emergency service system, mustfirst 
select an appropriate end-office switch. If there is only 
one choice (i.e., the PBX is connected to only one 
switch), then the decision is pre-determined. If there is 
more than one, then the on-site system must be config- 
ured to route 911 calls to end-office switches based up- 
on ELIN (or ERL). When the switch receives the call, it 
(or an agent of the switch) consults the ALI database to 
determine the proper PSAP to which the call should be 
routed. 

[0014] Once the PSAP receives the call, the location 
and callback information it gets is only as specific as is 
contained in the ELIN and the ALI database. That is, any 
site-specific mapping or location information that is not 
contained in the ERL definition in the ALI database is 
not passed in the call. Typically, calls outbound from a 
PBX do not pass internal extension information. This 
means that if an ERL contains several calling stations, 
the ALI will only locate the ERL, not individual calling 
stations. Also, even if each calling station has its own 
DID number, the PSAP will only receive the ELIN of the 
ERL; the on-site emergency system must incorporate 
intelligence to recognize that a 911 call has been made, 
and, if multi-station ERLs are used, to establish and 
maintain a mapping of ELIN to DID of the calling station 
(to support the event of call disconnection to the PSAP). 
Depending upon the level to which internal location in- 
formation is passed in outbound 911 calls, a PBX may 
actually have to multiplex call-back numbers across in- 
ternal location areas, rather than provide location- 
unique information to emergency response centers. To 
complicate matters further, the allowable size and defi- 
nition of such internal areas may be subject to different 
regulatory rules in different states or localities. 
[001 5] Unless each calling station is its own ERL, then 
sharing of ELINs among calling stations leads to the 
possibility of more than one concurrent 911 call using a 
single ELIN. While the ERL information in such a case 
would be correct, the callback information would be am- 
biguous, since the PSAP would have no way of uniquely 
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identifying the calling station beyond ELIN, and thus the 
PBX would not be able to de-multiplex a callback from 
the PSAP based upon ELIN alone. Note that while the 
ALI database must be regularly updated to reflect con- 
figuration changes in the PBX system, such updates are 
not intended to provide dynamic mapping on a call-by- 
call basis. 

[001 6] One way to deal with the case of multiple calls 
per ERL is to assign multiple ELINs to multi-station ER- 
Ls. Such a technique is used in the Emergency Re- 
sponse E-911 system by Cisco, for example. The 
number of ELINs per ERL can be determined according 
to the statistical probability of concurrent 911 calls in an 
ERL of a given size. As long as the number of ELINs 
assigned to an ERL is always greater than or equal to 
the number of concurrent 911 calls from that ERL, then 
there can always be a unique mapping of ELIN to calling 
station. One limitation is that "always" can not be guar- 
anteed except for the case of single-station ERLs. Given 
multi-station ERLs, the issue of the number of ELINs 
provisioned for each ERL is primarily one of cost: the 
PSTN service provider charges for each ELIN assigned. 
Thus for multi-station ERLs, there is a tradeoff between 
a "safe" ratio of calling stations to ELINs, and the cost 
of ELINs. The importance or relevance of this tradeoff 
is partially dependent upon the size and type of PBX. 
[0017] For example, in a traditional (TDM) PBX sys- 
tem that provides each calling station with a DID 
number, single-station ERLs are not necessarily an ex- 
cessive allocation of circuit resources. Since the service 
provider charges for each DID number, the PBX can, in 
principle, use each DID as an individual ELIN, thereby 
providing each calling station with its own ERL (and 
ELIN). This can work because, in a circuit-based PBX, 
even though each DID is typically associated with a per- 
son (e.g., employees at an enterprise), each is also as- 
signed to a specific calling station. Because a 911 call 
is tied to the ERL of the calling station, the DID number 
identifies the ERL. 

[0018] The situation is different in an IP-based PBX 
that uses, e.g., SIP. In this case, even if each person 
served by the PBX has an individual DID number, that 
number is not necessarily tied to a specific calling station 
(i.e., SIP phone). Rather, each DID number is associat- 
ed with a person, and any person could register at any 
SIP phone behind the PBX. As a result, no predictable 
association exists between personal DID numbers and 
ERLs. It is still possible to tie each calling station to an 
ERL by virtue of some hardware attribute and assign an 
ELIN to the ERL. However, in order to support single- 
station ERLs in this environment, a complete second set 
of hardware-identifying DID numbers would be required 
to assign one each to every calling station. While this 
would free personal DIDs to travel with each user, it 
could be expensive, and requires a burdensome level 
of provisioning of circuit resources. 
[001 9] in addition to the problems associated with the 
ELIN-DID mapping in multi-station ERLs in IP-based 


PBXs, LAN system and equipment configurations tend 
to be more fluid, in general, than circuit-based PBX sys- 
tems. Layer 2/3 switches can be moved or reconfigured, 
IP subnets can be modified, and SIP phones can be re- 
5 located. Within the context of E-91 1 service, this char- 
acteristic has the potential of translating into problems 
or difficulties in maintaining accurate location informa- 
tion, even for calling stations. Some solutions, such as 
the Cisco Emergency Responder, utilize a centralized 
10 device (e.g., the Emergency Responder node) to query 
a network device (e.g., the CallManager) to obtain a list 
of registered phones. The central device then queries 
individual switches to determine which physical ports 
are associated with those phones. Because a user's lo- 
ts cation may change at any moment, the central device 
must repeat this process continuously, if the time be- 
tween queries is short, the amount of network traffic can 
become large, and if the time interval is too long, the risk 
of improperly reporting the ERL increases. 
20 [0020] A LAN-based or VoIP-based PBX can intro- 
duce additional problems because internal extension 
numbers, which are usually associated with a person, 
may not be accurate indicators of location. For example, 
in the case of a SIP-based system, a given end user 
25 with a "fixed" phone number may actually register at ar- 
bitrary locations within network. If such a user makes a 
911 call, then the fixed phone number associated with 
that user may provide inaccurate, orworse, dangerously 
erroneous, location information. To address this prob- 
30 lem, a 911 caller's phone number must be mapped to a 
physical attribute of the phone, such as MAC address, 
which in turn may be associated with a current network 
location. 

[0021] While conceptually straightforward, this solu- 
35 lion brings with it added complexities, such as a new 
layer of indirection in the mapping, possible delay is- 
sues, and the need for a method for reliable location 
tracking of "portable" phones, among others. 
[0022] In addition, reliance on network-based call 
40 control elements in setup of 911 calls can introduce a 
failure point. While redundant elements may be added, 
this increases the expense and configuration of the 
E911 system. It also requires call control elements to 
reside on the same site as the phones in order to avoid 
45 WAN-based communications to complete a 911 call. In 
turn, this may add further expense for small sites that 
could otherwise use WAN-based communications for 
non-emergency calls. Consequently, a system that 
overcomes these limitations is desirable. 

so 

Summary of the Invention 

[0023] Described herein is a method of providing en- 
hanced emergency services (E-911) to an IPTelephony- 
55 based PBX or similar system, by utilizing aspects of the 
intelligence of end-user SIP client devices to address 
challenges and difficulties associated with E-911 -like 
services in LAN-based telephony environments. 
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[0024] The system and methods limit, or preferably 
eliminate, direct reliance on the IP Call Processing net- 
work element (e.g., SIP Proxy) during actual emergency 
calls. The system and method preferably incorporates 
processing capabilities of intelligent IP phones, in one 
embodiment, information necessary for initiating 911 
calls is stored in the phone. The information may include 
an ERL identifier, or one or more ELINs for identifying 
the source of the 911 call to the PSAP. 
[0025] Thus, one aspect of the preferred embodi- 
ments is to provide ERL information to an intelligent 
phone, thereby enabling it to place emergency calls di- 
rectly to a PSTN gateway, without involvement or aid of 
any other call signaling components. This also enables 
network configurations in which the call signaling com- 
ponent may be resident at a site remote from the intel- 
ligent phones, without the danger of a failed inter-site 
link causing an inability in placing an emergency call. 
[0026] In one preferred embodiment, the IP phone 
communicates directly to a PSTN gateway, bypassing 
any signaling agents typically used to set up a call. In 
an alternative embodiment, the call is initiated by com- 
municating with call signaling elements, such as a SIP 
Proxy device. In either embodiment, the method prefer- 
ably includes providing the phone with ERL information 
(in the form of one or more ELINs) to provide to the gate- 
way or call signaling element. Further aspects of pre- 
ferred embodiments include providing the phone with a 
default gateway identifier, thereby allowing the phone to 
identify a default PSTN gateway to use for 911 calls 
when bypassing the normal signaling elements. The 
ERL, ELIN and/or default gateway identifier information 
may be provided during the phone's boot-up procedure, 
or using subsequent signaling messages. 
[0027] A location server preferably stores the ERL 
and associated ELINs. as well as default gateway iden- 
tifier information. In addition, the location server prefer- 
ably stores location information associated with the IP 
phone. A further aspect of preferred method is the use 
of an intelligent PSTN gateway that is capable of receiv- 
ing and acting upon IP-based call setup signaling direct- 
ly from IP phones, as well as implementing some ancil- 
lary functions associated with 911 calis. 
[0028] There are numerous network management 
tools and systems that can auto-detect network topolo- 
gy and operational state. An element of E-911 service 
in an IP-based PBX, then, is interfacing to, or integration 
of, the appropriate network management functions that 
ensure accurate and reliable location information. 
[0029] An additional feature of certain preferred em- 
bodiments includes automatic discovery of intelligent 
phone location when the phone registers with the sys- 
tem. This may involve the merger of the network man- 
agement system with the signaling system to be able to 
find device. The preferred embodiments include a Lo- 
cation Server asthe architectural element of the network 
that bridges the call signaling components and the net- 
work management components. The location server, 


based on the MAC address of a calling device or an IP 
address assigned to a calling device, is able to deter- 
mine a physical port associated with the device. The de- 
termination may be made through a network manage- 

s ment system. 

[0030] In another aspect of certain preferred embod- 
iments, the intelligent phone enters into a state of emer- 
gency readiness before presenting dial tone, and with- 
out the need for a specific user to register in the network 

10 via the phone. This may support, e.g., public phones, at 
which no user is registered, but from which calls, in par- 
ticular emergency calls, may be placed. 
[0031] Still further aspects include certain actions by 
the intelligent phone for ensuring that emergency calls 

15 cannot be disrupted by otherwise normal call signaling 
events to the phone. These include sending a notifica- 
tion to the network signaling agent (e.g., SIP Proxy) in- 
forming it that an emergency call has been placed; or 
deregistering the user from the phone (via SIP signaling 

20 to the Proxy), so that the IP network will not even try to 
place calls to the phone. 

[0032] Additional aspects include actions by the intel- 
ligent phone for ensuring that emergency calls cannot 
be released by the caller once the call has been con- 

25 nected to the PSAP. These include declining to generate 
and/or send the appropriate IP-based signaling mes- 
sage^) that would initiate the call release sequence, in 
addition or instead, the phone could automatically acti- 
vate its speaker and/or microphone if and when the call- 

30 er attempts to release a connected emergency call. This 
feature may be easily extended to systems utilizing vid- 
eo phonefeatures or capabilrties to provide a monitoring 
function. 

[0033] Yet another feature of the system is a PSTN 
35 gateway that is configured to accept direct signaling 
from intelligent phones in the case of emergency calls. 
That is, the preferred gateway includes a SIP stack to 
accept an invite from something other than a SIP proxy. 
In certain embodiments, the gateway stores ERL and 
40 associated lists of ELINs for use in initiating an outgoing 
91 1 call. The preferred PSTN gateway is also configura- 
ble to provide priority handling to emergency calls. In 
addition, the gateway preferably maintains a record of 
in-use ELINs, performs ELIN management, generates 
45 CDRs associated with emergency calls, sends a notifi- 
cation to the safety/security station when the call is 
placed, and provides backup storage of intelligent 
phones' ERL information. 

so Brief Description of the Drawings 

[0034] Examples of the present invention will now be 
described in detail with reference to the accompanying 
drawings, in which: 

55 

FIG. 1 is a block diagram illustrating one embodi- 
ment of a high-level reference architecture; 
FIG. 2 illustrates the functional elements of E-911 
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service in one preferred embodiment; 
FIG. 3 illustrates a preferred embodiment of a loca- 
tion server and database; 
FIG, 4 illustrates a preferred method of configuring 
a phone for emergency state readiness; s 
FIG. 5 illustrates an alternative preferred method of 
configuring a phone for emergency state readiness; 
FIG. 6 is a call signaling flowchart for phone initia- 
tion; and 

FIG. 7 is a call signaling flowchart for establishing 10 
a 911 emergency call. 

Detailed Description 

A. Reference Architects re * 5 

[0035] The basic components of IP-based E-911 
service are illustrated in Figure 1 , which depicts a high- 
level reference architecture of a preferred embodiment. 
The elements are shown to reside either behind the IP 20 
PBX (Enterprise Premise area 102) or in the PSTN 
space (Service Provider & PSAPs area 104). Multi-sta- ' 
tion emergency response locations ERL1 and ERL2 re- 
side in the enterprise area 1 02. ERL1 may be associat- 
ed with a description of the Emergency Response Lo- 25 
cation, for example, of 3200 Main Street, 3 rd floor, and 
ERL2 may be associated with a description of 3200 
Main Street, 2 nd floor, cubes 5 through 7. Note that ERL1 
has two ELINs, while ERL2 has just one. 
[0036] The physical connection points to the network so 
are preferably provided by some form of jack (e.g., an 
RJ45) which are identified with physical locations. An 
example physical location is jack 106, indicated for the 
bottom-most connection point in Figure 1 , which might 
be an RJ-45 jack located on the second floor, cubicle 7. 35 
Other types of connection hardware and networking 
may be used, such as token ring, optical fiber, and wire- 
less ports (e.g., B02.11 , Bluetooth, etc.). In Figure 1 , an 
IP phone (e.g., phone 108) is connected to each man- 
aged physical connection point 1 06, which is connected 40 
to a single managed port 1 21 . The phones may use the 
Session Initiation Protocol (SIP), for example, but other 
types of IP-based phones may also be used. The 
phones may be dedicated programmable hardware, or 
soft-clients running on, e.g., desktop computers. ^ 
[0037] The PSTN side 104 includes a Central Office 
(CO) switch 110, an A LI database 112, and two PSAPs 
114, 116. There may be more or fewer of each of these 
components. Note that the enterprise side 1 02 may ac- 
tually be distributed over multiple sites or campuses. In so 
such an embodiment, it is assumed that some form of 
secure managed links is maintained between individual 
sites. As examples, VPN connections over IPsec, or pri- 
vate leased lines may be used. 

[0038] Managed Layer 2/3 switch 1 1 8 is the managed 55 
switch that provides the first point of connectivity to the 
network for the IP phones (and other IP client devices). 
As illustrated, ports 1 20 on the switch 1 1 8 are connected 


directly to the managed physical connection points, 
such as port 1 06. The switch 1 1 8 is typically resident at 
the same site as the phones (and other devices), which 
use it to connect to the local I P network. Note that there 
may be other switches at topologicaiiy higher levels In 
the network. 

[0039] The managed router 122 represents the man- 
aged network infrastructure above the managed switch 
118. That is, there may be a multiplicity of routers and 
related devices (e.g., DHCP servers, AAA servers, etc.). 
From the point of view of determining the location of IP 
phones, only the managed switch 11 8 is relevant. Thus, 
only a single representative router 122 is shown in Fig- 
ure 1 . In embodiments having multiples sites, each site 
may have one or more routers. 
[0040] An IP Call Processing network element 124 is 
responsible for IP-based signaling and call control. For 
example, in a SIP-base system, this may be a SIP Proxy 
server. The Call Processing element 124 may be locat- 
ed at the same site as the phones that it services, or 
may be located remotely at a different (possibly central) 
site. If remotely located, the relevant signal messaging 
will traverse the inter-site connections (e.g., secure 
VPNs). 

[0041] The Location Server 126 is a network element 
that keeps track of where phones are located, maintain- 
ing the information in a database. This element may be 
located at the same site as the phones, or remotely, at 
a different (possibly central) site. If remote, the relevant 
communications with other network elements may 
traverse the inter-site connections (e.g., secure VPNs). 
[0042] Network management system (NMS) 1 28 is a 
combination of hardware and software that monitors 
and manages the network. In the context of E-911 serv- 
ices, the NMS 128 should be capable of discovering the 
location of any IP phone, as specified by the managed 
switch 1 1 8 and switch port 120 to which the phone con- 
nects. The NMS 128 may be located at the same site 
as the phones, or remotely, at a different (possibly cen- 
tral) site. If remote, the relevant communications with 
other network elements may traverse the inter-site con- 
nections (e.g., secure VPNs). 

[0043] The PSTN gateway 130 provides an interface 
to the CO switch 110 (e.g., via PRI lines) on the PSTN 
side, and IP connectivity (e.g., via RTP) on the IP net- 
work side. The gateway 1 30 may interact with the IP Call 
Processing element 124 in order to manage calls, but 
may also be able to communicate directly with intelligent 
IP phones for this purpose. The gateway element 130 
is typically on the same site as the phones that it serv- 
ices, since it is preferably connected to the local PSTN. 
However, it could be at a remote site, but preferably is 
able to place PSTN calls to the appropriate PSAP for 
the phones that it services. In addition, it is desirable for 
the gateway 130 to be able to establish and maintain 
reliable IP connectivity to those phones across the inter- 
site IP links. 

[0044] The On-site Security Station 132 is a monitor- 
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ing station at which security/safety personnel may ob- 
tain real-time status and information on emergency calls 
placed to a PSAP. it must be on the same site as the 
phones that it services. That is, it is intended to support 
on-site personnel in responding to local (same site) 
emergency calls. 

[0045] In Figure 1, all of the above elements are 
shown to have physical connections (solid iines) to the 
network (represented by the Managed Router 122). 
Logical links, shown as zig-zag lines, indicate which el- 
ements communicate with each other in the implemen- 
tation of E-911 services. Only a single, representative 
phone 1 08 is shown to have such links; it should be un- 
derstood that all phones may have similar logical links. 
Note that not all possible communications links are 
shown, and that others are possible. Finally, there may 
be other elements of a local data and IP telephony net- 
work which are not shown in Figure 1 . These may in- 
clude other application servers, multimedia servers, etc. 
It should be understood that their omission from Figure 
1 does not exclude their possible presence in a network 
that supports E-911 services. 

B. Exemplary Method for Emergency Telephony 
Services 

[0046] In the following descriptions of preferred em- 
bodiments, the IP telephony network is assumed to be 
based upon SIP, and SIP messaging is used to illustrate 
the system and method. However, other protocols that 
support direct signaling and call control messaging be- 
tween the IP phones and the PSTN gateway are also 
possible (e.g., H.323). First the functional architecture 
is presented, followed by a description of system initial- 
ization, and finally actual call processing. In addition, 
some configuration and provisioning considerations are 
discussed. 

1 . Functional Architecture 

[0047] Figure 2 illustrates the functional elements of 
E-911 service in a preferred system, as well as the ar- 
chitectural relationships among them. The elements in- 
clude a SIP phone 202, Managed Access Switch Port 
204, 911 Location Server and Database 206, PSTN 
Gateway 20B, DHCP Server 210, Software Image 
Download Server 21 2, NMS 214, SIP Proxy Server 21 6, 
Local Security Station 218, Accounting Server 220, ALI 
Liaison Server 222, and Provisioning Server 224. 
[0048] SIP phone 202 is the calling station from which 
911 calls may be placed. It includes processing intelli- 
gence; i.e., a SIP user agent for support of the SIP pro- 
tocol, plus additional application capabilities for fea- 
tures, functions and services, including speaker mode. 
Phone 202 uses DHCP to obtain an IP address, and 
may also obtain other custom options via DHCP. Cus- 
tom options may be used, for example, to identify the 
Software Image Download server, oradefaultSIP Proxy 


server. The SIP phone does not necessarily support 
SNMP. However, phone 202 does support the 91 1 -spe- 
cific functionality associated with this system and meth- 
od. 

s [0049] The Managed Access Switch Port 204 typically 
identifies the first layer 2/3 switch and switch port within 
the managed network infrastructure to which the SIP 
phone connects for access to the local IP network. This 
typically does not include any layer 2 devices that may 

10 possibly be deployed between the phone and the first 
managed switch; e.g., a desktop switch which is not part 
of the managed infrastructure. The managed switch 
preferably supports SNMP, or an alternative network 
management protocol. 

is [0050] The 911 Location Server Database 206 is a 
centralized server that preferably maintains two data- 
bases: an ERL database 302, and a Phone Location da- 
tabase 304, as shown in Figure 3. The ERL database 
typically stores one record 305 for each ERL in the cam- 

20 pus or site served by the emergency system. Each ERL 
record 305 preferably contains the following informa- 
tion: ERL identification 308; Assigned managed switch 
and switch ports 31 0; Assigned managed physical con- 
nection points 312; Assigned ELINs 314; Assigned 

25 PSTN gateways 31 6; and Location Description 31 8. Al- 
ternative ERL records may contain a subset of these pa- 
rameters, and may also include others not listed here. 
[0051] The composite information in an ERL record 
305 defines the ERL. ERL definitions are created first 

30 n on paper" as part of a site management process that 
may or may not lend itself to automation. That is, the 
assignments of switch ports, ELINs, etc., to an ERL may 
depend upon the physical layout of the site, and hence 
require human decision making. The ERL records in the 

35 database may be populated as part of a provisioning/ 
configuration process. 

[0052] The Phone Location database 304 stores one 
record 319 for each registered phone in the system. 
Each phone location record 31 9 preferably contains the 

40 following information: IP address 320 of the phone; As- 
signed ERL 322 (ERL identification); Assigned man- 
aged switch and switch port 324; Assigned managed 
physical connection point 326 (only if port-to-connection 
point is one-to-one); Assigned ELINs 328; Assigned 

45 PSTN gateways 330; MAC address 332 of the phone; 
and Serial Number 334 of the phone. Additional infor- 
mation may also be contained in the phone location 
record. 

[0053] Note that an ERL record 305 may contain mul- 
50 tipie switch ports 310 and multiple physical connection 
points 312, while a phone location record 319 contains 
only a single switch port 324 and single physical con- 
nection point 326. That is, an ERL serves one or more 
possible switch ports 120, while a phone 202, 108 is 
55 served by one of each of these entities (i.e., one physical 
connection point, and one switch port). In contrast, each 
phone may be served by all of the ELINs and PSTN 
gateways assigned to its ERL. Note also that, if a single 
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switch port is connected to multiple managed connec- 
tion points (e.g., several cubes sharing access to a 
switch port), then it is not possible to determine the con- 
nection pointfrom a phone's IP address. In such cases, 
its physical connection point may be omitted from the 
Phone Location record. However, typical LAN configu- 
rations do use one-to-one assignments of switch ports 
to physical connection points. In these cases, the switch 
port is equivalent to the physical connection point, pro- 
vided the mapping information is maintained. 
[0054] The process for populating the Phone Location 
database is dynamic, executing in response to a request 
to the 911 Location server from the SIP Proxy server 
216. Given an initial request from SIP Proxy server216 
with the IP address or MAC address of a SIP phone, the 
91 1 Location Server 206 discovers the Managed Access 
Switch port 204 forthe phone, and uses the switch port 
identification 324 to index the associated ERL record. A 
new Phone Location record 31 9 is then created, and the 
associated information loaded. Subsequent requests 
from the SIP Proxy Server 216 using the same IP ad- 
dress or MAG address may cause the Phone Location 
record 319 to be retrieved, or a new location discovery 
process to be launched. A new discovery process may 
result in updated location information, which may be 
used to upSate the Phone Location record 319. 
[0055] It should be understood that the descriptions 
of these databases are illustrative, and they may be im- 
plemented in multiple ways. The description herein is 
one of many ways. For example, alternative embodi- 
ments may use less information and fewer data fields, 
orthere may be additional information in additional data 
fields included in these databases. In addition, the 911 
Location Server databases 302. 304 may serve phones 
that are co-resident at the same site, or resident at a site 
remote from the server. 

[0056] The PSTN gateway 208 provides PSTN con- 
nectivity to the packet-based phone system. For a given 
SIP phone, this is the specific media gateway, or set of 
media gateways, from among a possible plurality of me- 
dia gateways available to the phone, that provides ac- 
cess to the PSTN for 911 calls. The Gateway 208 termi- 
nates SIP calls from, and originates SIP calls to, the SIP 
phones that it serves. It also supports additional SIP 
functionality for communication with the Local Security 
Server 218. if multiple PSTN gateways are available, 
each SIP phone may be assigned a prioritized list for 
backup/reliability purposes. In addition, the PSTN gate- 
way 208 supports some ancillary tasks associate with 
911 calls, including maintaining a record of ELINs that 
are in use, and maintaining minimal call-state informa- 
tion specific to active 911 calls. 
[0057] The DHCP Server 210 provides IP client de- 
vices such as SIP phone 108 with IP addresses and oth- 
er parameters when they first start up, and upon subse- 
quent request. DHCP server 210 responds to the SIP 
phone's initial DHCP request for IP access in the local 
network. In addition to an IP address, the DHCP re- 


sponse message may include custom options, such as 
identification of a Software Image Download Server 
212. 

[0058] The Software image Download Server 212 
5 provides each SIP phone with its software Image when 
it initializes, or boots up, through the use of a download 
request message and a download response. Note that 
other methods of supplying the SIP phone with its soft- 
ware image are possible, such as non-volatile ROM or 
10 RAM storage in the phone. Such alternative methods 
may eliminate the need forthe Software Image Down- 
load server 21 2. 

[0059] The Network Management System (NMS) 21 4 
is a combination of hardware and software that monitors 

15 and manages the network. It may reside in a remote or 
central site, but can still perform basic network manage- 
ment functions, such as device discovery, and topology 
mapping in the local network. In particular, the Network 
Management System 214 may discover the Managed 

20 Access Switch port 204, given the IP address or MAC 
address of a connected SIP phone. It may also be used 
to discover if any unmanaged switches are in the path 
between the SIP phone and the Managed Access 
Switch port. In a preferred embodiment it uses the 

25 SNMP protocol to communicate with the various net- 
work components. 

[0060] The SIP Proxy Server 216 is the IP Call 
Processing network element 124 in a SIP-based sys- 
tem. SIP Proxy Server 216 may reside in a remote or 
30 central site. 

[0061] The Local Security Station Sever 218 is the 
monitoring station in an on-site system that may be mon- 
itored by security/safety personnel. This station pro- 
vides alerts when 911 calls are placed, and supplies ad- 
35 ditional location information that may not be available in 
the ERL definition in the ALl database. For example, the 
switch port to which the SIP phone is connected may be 
used to identify a specific location, such as an office or 
cubicle. It may also provide web-based user interface. 
40 [0062] The Accounting Server 220 is a repository of 
records related to calls that have been made in the sys- 
tem. Accounting Server 220 is a sever suitable for main- 
taining call detail records, as well as associated man- 
agement functions, such as reading, writing, and updat- 
es jng records. In particular, it maintains call detail records 
associated with emergency calls. 
[0063] The ALl Liaison Server 222 is an application 
that converts the system's ERL information, in particular 
Location Description 31 8, into a format compatible with 
so the ALl database maintained by the LEC or service pro- 
vider. The ALl liaison is configurable to adapt to multiple 
ALl database formats used by LECs and service provid- 
ers. 

[0064] The Provisioning Server 224 is a server that 
55 allows network managers and operations personnel to 
create/update provisioned data and parameters of the 
system such as user accounts and authorizations. In the 
context of E-911 service, it can be used to manually pop- 


9 


NSDOCID: <EP 1 526697 A2_l_> 


17 


EP1 526 697 A2 


1B 


ulate the ERL database in the 911 Location server. 
[0065] Note that some of these elements, such as the 
SIP Proxy Server 21 6, the PSTN Gateway 208, and the 
Accounting Server 220, may be common to other func- 
tions of an IP telephony system, besides E-911 service. 
In addition, some elements used in the operation of an 
IP telephony system, but not specifically in E-911 serv- 
ice, may be omitted from the figure for clarity. Interfaces 
between elements are represented by specific proto- 
cols, identified in the double arrows connecting the ele- 
ments. The interface identified simply as "IP" supports 
standard IP communications, without reference to spe- 
cific high-layer protocols. Similarly, the arrow labeled 
"L2/L3" represents the basic, low-layer support of all up- 
per-layer protocols. Note that "3Q" is a 3Com protocol 
which issimilarto RADIUS. Thus, RADIUS or other suit- 
able protocols (e.g., DIAMETER) may be used in alter- 
native embodiments. The arrows 230, 232, 234, 236, 
represent information flow through an API or interactive 
user interface. All of the protocols in this illustration are 
exemplary, and alternative suitable protocols may be 
used. 

[0066] In Figure 2, the dotted circle 238 surrounding 
the SIP phone 202 identifies ail the protocol interfaces 
that are supported by the phone's physical connection 
to the Managed Access Switch port 204, The switch port 
204 itself is included explicitly because it provides the 
most precise physical location for the phone 202 that is 
known to the overall system, and therefore performs a 
functional role in enabling E-911 service. Note that the 
management of the switcn port 204 by the Network Man- 
agement System 21 4 is also explicitly shown (via SNMP 
In this illustration). For ail the other indicated protocol 
interfaces, the switch port 204 provides the usual net- 
work access, and thus is omitted from the communica- 
tion paths depicted in Figure 2 for clarity. 

2. System Configuration 

[0067] When an IP telephony system is deployed at 
an enterprise or camp us, each ERL is preferably defined 
in terms of the Managed Access Switch ports and phys- 
ical connection points that will be included. The process 
of mapping the topology of these switch ports may be 
an automated feature of the Network Management Sys- 
tem, but the task of assigning individual switch ports and 
connection points to specific ERLs requires human de- 
cision making. The task of assigning an ELIN or ELINs 
to each ERL is similarly discretionary. 
[0068] Assignment of the PSTN gateway or gateways 
may be determined in part by requirements of the LEC, 
but may also include some discretion on the part of the 
site management. The considerations that go into mak- 
ing the assignments may include state and/or local reg- 
ulation, as well as preferences of the site management 
personnel. 

[0069] Once the configuration is defined, it is provi- 
sioned in the 911 Location Server database 206. Each 


Managed Access Switch port 204 is included in an ERL 
record 305, which preferably contains the information 
shown in Figure 3, and discussed above. Again, other 
information may be added to the ERL record 305. For 

5 example, when a SIP phone 108 registers : it becomes 
associated with an ERL, by virtue of the phone's phys- 
ical connection point 1 06 and switch port 121 . The ERL 
record may be dynamically extended to include the IP 
and/or MAC addresses of all associated and/or regis- 

10 tered SIP phones. Other ancillary information may also 
be included in the record, such as, phone extension 
numbers, cube numbers, names of employees as- 
signed to the locations (areas, offices, cubes, etc.), text 
or image-based descriptions of the location, and any 

15 other relevant information (including file names or URL 
or other links to additional information) that may be use- 
ful in assisting emergency response teams. 
[0070] Anytime the network configuration is modified, 
the provisioning information associated with the ERL 

20 records is preferably updated. Modifications include, but 
are not limited to, adding/removing switch ports to/from 
ah existing ERL, adding/removing ERLs, and modifying 
network switch interconnections or topologies. As de- 
scribed below, the system also includes periodic self- 

25 consistency checks in order to detect any such modifi- 
cations for which the provisioning updates wets net 
made, or were made incorrectly. 

3, SIP Phone Initialization and Default Registration 

30 

[0071] The method 400 of SIP phone initialization and 
default registration shown in Figure 4 illustrates how a 
SIP phone first achieves a state of emergency services 
readiness (that is, a state in which any arbitrary end user 

35 may use the phone to place a 91 1 call). This may be an 
appropriate state for a public phone; no actual user reg- 
istration would be required. The steps outlined below 
describe a preferred embodiment of the system and 
method, and it should be understood that alternative im- 

40 plementations may be used to achieve the desired re- 
sults. Some of the possible alternatives are noted as 
well, but these are not intended to represent the full 
range of implementation approaches. 
[0072] In a preferred method 400, the phone first reg- 

45 isters (step 402) with the system using a configuration 
associated with a default profile. The system then de- 
termines (step 404) the ERL information associated with 
the phone based on the phone's location, and at least a 
subset of the ERL Information is then provided (step 

so 406) to the phone. The ERL information provided to the 
phone preferably includes one or more ELINs that may 
be used when the phone initiates an emergency 911 
call. 

[0073] In an alternative embodiment shown in Figure 
55 5, a preferred method 500 operates as follows: when a 
SIP phone (e.g., phone 202) is first connected to the 
Managed Access Switch port 204 and powered on, it is 
initialized, as shown at step 502. Initialization involves 
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booting the phone 202 with its operational software and 
generally registering on the network, by, e.g., obtaining 
an IP address. Preferably, the phone will issue a DHCP 
request to initially obtain its IP address. Assuming the 
phone 202 acquires its software image from a download 
server 212, the DHCP response may also contain the 
address of this server in an option data field of the mes- 
sage. Similarly, the address of the SIP Proxy server 21 6 
may be included in a DHCP option field, if a download 
server 212 is not used, then the associated option may 
be omitted; the address of the SIP Proxy 216 may be 
determined in another manner, such as pre-configuring 
the information in the phone 202. 
[0074] In one preferred embodiment of step 502, the 
phone 202 will next request its software image from the 
download server 212. After download, the phone will 
boot the image and again contact the DHCP server210 
to renew/reinitialize its lease, and possibly request a 
new IP address on a specific sub net This second DHCP 
request may be omitted from step 502 if the phone's 
software resides locally on the phone 202 in RAM or 
ROM memory. 

[0075] At step 504, the phone 202 performs default 
registration. Typically the phone 202 will issue a SIP 
REGISTER message to its SIP Proxy server 216 in or- 
der to obtain a default registration; this message may 
also contain information about the phone hardware if it 
is relevant to the SIP Proxy's actions. Note that this re- 
quest is not associated with any specific end user, but 
with the phone itself. Upon receipt of the SIP registration 
request, the SIP Proxy server 21 6 will access a default 
profile for the phone, either from a local cache, or an 
external profile server. The profile may contain such in- 
formation as keypad mapping, allowed functions, etc., 
for default operation of the phone. 
[0076] At step 506, the relevant ERL information is ob- 
tained. Preferably, SIP Proxy 216 will issue a requestto 
the 911 Location Server 206 for the ERL information for 
the SIP phone 202, passing the phone's IP and/or MAC 
address as its identifier. In some embodiments, the lo- 
cation server does not populate or dynamically update 
its database of phone identification records 31 9 until a 
query is received. In such embodiments, the initial re- 
quest for this phone may result in the absence of a 
record 31 9 f orthis IP and/or MAC address. Thus, at step 
508, the 91 1 Location Server will use the phone's I P and/ 
or MAC address in a request to the Network Manage- 
ment system for the identity of the Managed Access 
Switch port to which the phone is connected. Step 508 
may be omitted in embodiments where the phone loca- 
tion record is updated via other means, typically asso- 
ciated with the phone registration (for example, in re- 
sponse to a DHCP request or DHCP response, or soft- 
ware image download, etc.). In further alternative em- 
bodiments, the database information may be co-located 
or merged with the SIP proxy function. 
[0077] The Network Management system 21 4 may al- 
so be able to determine if there are any intervening, un- 


managed switches between the phone and the man- 
aged switch port. The Network Management system 
214 will provide the switch port identification in its re- 
sponse (or in its dynamic update) to the 911 Location 

5 server 206, along with the identity of any intervening, 
unmanaged switches. If there are any unmanaged 
switches in the path between the phone and the man- 
aged switch port, then the 911 Location server 206 may 
choose to deny admission of the phone into the system. 

10 Such an action would prevent potentially bogus location 
information from being entered into the database. The 
action may also be accompanied by an alert to the NMS 
214, or similar monitoring function, allowing for correc- 
tive action to be taken. If the phone 202 is connected 

15 directly to the managed switch port 204, then the 911 
Location server 206 uses the switch port identification 
to lookup the associated ERL record in step 510, and at 
least a subset of the information in the record is returned 
to the SIP Proxy. Preferably, the ERL information pro- 

20 vided to the SIP Proxy includes a list of ELINS for the 
ERL. Alternative embodiments may include other infor- 
mation such as text description of the location, cube or 
office number, occupant(s), etc. A Phone Location 
record 319 is also created (or updated) for the phone, 

25 and entered into the Phone Location database. 

[0078] When the SIP Proxy receives the ERL infor- 
mation, it sends at least a subset of it to the SIP phone 
at step 512. The subset includes one or more ELlNs for 
use in a subsequent emergency 911 call. The ERL in- 

30 formation is preferably sent in the OK message, along 
with the phone's default profile, to complete the regis- 
tration transaction. The SIP phone activates its default 
profile, and Internally stores Its ERL information for use 
in the event that a 911 call is placed. Once the default 

35 registration is successful the SIP phone may receive di- 
al-tone, indicating that it has achieved the state of emer- 
gency services readiness. Note that any subsequent, 
user-specific registrations will not invalidate the ERL in- 
formation received by the phone during default registra- 

40 tion. For example, a specific user may register with a 
personal profile at the phone without affecting the de- 
fault registration state or default profile of the phone. 
[0079] Figure 6 is a call flow showing the initialization 
procedure. In this example, the SIP phone sends a DH- 

45 CP request (step 601) to obtain an initial IP address 
(step 601 A). Then phone 1 08 sends a download request 
for a boot image (step 602). The phone receives a soft- 
ware image (step 602A), and a VLAN tag, and issues a 
second DHCP request using the VLAN tag (step 603). 

so The phone may then register with the network (step 

604) , which in this case uses SIP signaling and a SIP 
proxy. The SIP proxy queries the location server (step 

605) , and upon receiving the response, sends the SIP 
OK message containing the ERL record along with the 

55 default profile (step 606), preferably as a textual descrip- 
tion in the body of the SIP OK message. 
[0080] Figure 6 thus illustrates how voice traffic may 
be kept on a specific VLAN within a local IP network, in 
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addition, an optional action (step 607) is shown in which 
the PSTN gateway provides local backup storage of the 
phones ERL information, it should be understood that 
the exact steps, as well as their sequence, are illustra- 
tive, and alternative call flows may be used. s 

4. 911 Call Processing 

[0081] With reference to Figure 7, when a 911 call is 
placed from a registered SIP phone 1 08 (default or user- 10 
specific registration), the SIP phone 1 08 user agent ap- 
plication will retrieve the stored ERL information and for- 
mulate a SIP INVITE message 701 containing the ERL 
information for transmission to the PSTN gateway 208. 
The ERL information may be included in an associated 
SDP, but other methods of inclusion of the ERL data in 
the INVITE message 701 are possible. In one embodi- 
ment, the INVITE message 701 is sent directly to the 
PSTN gateway 208; i.e., it is not directed to the SIP 
Proxy 216. The phone 108 then sends a SIP NOTIFY 
directly to the Local Security station 21 8. 
[0082] Upon receiving the SIP INVITE message 701 , 
the PSTN gateway 208 places an outbound call 701 A 
on the appropriate PSTN interface. The PSTN signaling 
in this example is based on SS7/ISUP, but other signal- 
ing could be used, for example PRI. Note that PSTN sig- 
naling elements for handling SS7/ISUP are not shown 
in Figure 7. The call may be to the local CO switch, which 
will direct the call to a 91 1 tandem switch for processing. 
Alternatively, the PSTN gateway 208 may have a spe- 
cific interface for 911 calls. Either way, the gateway 208 
will examine the Service Description Protocol (SDP) 
message (or other appropriate message elements) In 
the INVITE message 701 in orderto determine the ERL. 
The SDP preferably includes the ERL record 305, or 
may include only an associated ERL ID 308, or one or 
more assigned ELINs from the list of ELINs 314. It will 
then examine the list of (possibly multiple) ELINs, and 
select one that does not match any that may already be 
included in its list of in-use ELINs. The selected ELIN is 
used to set the ANI in the outbound call 701 A. The ELIN 
will then be recorded (possibly along with other ELINs), 
effectively marking it as in-use for any subsequent 91 1 
calls from the same ERL. Along with the ELIN, the list 
may also contain additional identifying information 
about the location of the calling station; for example, the 
phone's IP address and the ERL identifier. 
[0083] Once the call is placed to the PSTN, the gate- 
way 208 will send a SIP NOTIFY message 704 to the 
Local Security station 21 8 with the status of the call. The 
gateway 208 will also generate CDRs (Call Detail 
Records) at various stages of each 91 1 call episode, and 
send them (706) to the Accounting Server 220; for ex- 
ample, when the call is placed to the PSTN, when the 
call terminates, etc. 

[0084] For the duration of the call, the PSTN gateway 
208 must be able to map any inbound call from the 
PSAP to the assigned ELI N to the original calling station . 


However, the gateway 208 must block any other calls 
inbound to the assigned ELIN. 
[0085] The Local Security station 218 preferably in- 
cludes an application that correlates SIP NOTIFYs 702 
for 911 calls from SIP phones with SIP NOTIFYs 704 
from the PSTN gateway 208. This will help insure relia- 
bility of the system, since the security station can be 
made to expect a notification from the gateway 208 that 
the call has been placed. If such notification is not re- 
ceived, the security station can be alerted, and the mon- 
itoring personnel can take appropriate backup action. In 
a duplicate action with the gateway 208, the Local Se- 
curity station will also generate CDRs 705 at various 
stages of each 911 call episode, and send them to the 
Accounting Server 220. 

[0086] The Accounting Server 220 will correlate and 
merge CDRs on each 911 call. They will be available for 
viewing and analysis at a later time, as well as docu- 
menting the call. 

[0087] Once the call has been handled and terminat- 
ed normally (i.e., the emergency situation is known to 
have been handled and cleared by the PSAP), call tear- 
down proceeds as usual. When complete, the call status 
is cleared from all the relevant database elements, and 
the list of in-use ELINs at the PSTN gateway 208 is 
cleared of the associated call entry. If a particular call is 
terminated, but there is no clear indication thattheemer- 
gency situation has been resolved, then the in-use sta- 
tus of the associated ELIN is maintained, as is the list 
at the gateway 208. After a configurable time limit, if no 
further information is received regarding the call, it is as- 
sumed to be resolved, and the ELIN is freed up and the 
list is cleared of that entry. All call status changes during 
the call, Including termination, will cause the gateway to 
issue SIP NOTIFY messages to the Local Security sta- 
tion, in addition, some or ail of the same status changes 
will cause the gateway 208 to generate related CDRs to 
the Accounting Server 220. 

[0088] While a 91 1 call is active, the assigned ELIN is 
marked as in-use, by virtue of its presence in the PSTN 
gateway's 208 list. Any subsequent 911 calls from the 
same ERL while the ELIN is in use should be assigned 
a different ELIN for that ERL. For example, the gateway 
208 may compare the list of ELINs in a SIP INVITE with 
the list of ELINs in its list to make this determination. 
However, depending upon the number or ELINs per 
ERL, there could arise a circumstance in which a 911 
call is made from an ERL when all ELINs for that ERL 
are active (in-use). In this case, the PSTN gateway 208 
preferably employs an algorithm to select which of the 
in-use ELINs for the particular ERL should be re-as- 
signed to the new 91 1 call. For example, the ELIN which 
has been in-use for the longest time could be assigned 
to the new call. Note that this will invalidate the previous 
mapping of the ELIN to the original calling station 108. 
However, the relevant call information, even if it includes 
a multiply-assigned ELIN, can be maintained at the 
gateway 208 and/or the security stations forthe duration 
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of the calls. 

[0089] Note that once a call Is established from a call- 
ing station 108 to a PSAP, it must not be disrupted by 
otherwise normal call signaling events. For example, the 
calling station 108 should not receive any call-waiting 
messages, or other advanced calling feature signals. 
This can be achieved with the SIP phone 1 08 simply by 
having the phone 1 08 use only its default profile once a 
911 call is placed from it, and signaling the SIP Proxy 
216 to block any inbound signaling to the phone 108. 
Alternatively, if there is an active personal registration 
(and personal profile) at a SIP phone 108 when a 911 
call is placed, the phone 1 08 may automatically de-reg- 
ister that user from the phone 108. This has the effect 
of blocking any signaling to the user at that specific 
phone 108, since the SIP Proxy 216 would no longer 
see the user as reachable at the phone 108. Note that 
calls to that user could still be placed to any other SIP 
user agents at which he/she is registered. Again, there 
may be other ways to accomplish the non-disruption 
feature. 

[0090] The phone's user agent application may also 
ensure that, once connected to the PSAP, the call can- 
not be released by the caller. For example, once a 911 
call is active, the user agent application can simply de- 
cline to send a SIP BYE message if the user hangs up 
the phone 108. in addition or instead, the phone 108 
may automatically activate its speaker and/or micro- 
phone if the user hangs up. This way, the PSAP could 
maintain a monitor at the phone's location, even if the 
user does not participate further in the call. Such a mode 
of operation could be advantageous, for example, in an 
intrusion situation. 

Location Verification Management 

[0091] Location verification management includes the 
methods, processes, and triggers used to discover lo- 
cation information for each calling station and ERL; pop- 
ulate the information elements of the location server da- 
tabase; and periodically check and verify the validity of 
database information, perform any required updates, 
and generate any alarms or alerts. 
These are covered in following subsections. 

1. Network Topology Considerations 

[0092] One challenge in devising a location manage- 
ment strategy is that network topologies can differ from 
LAN to LAN, and enterprise to enterprise. In the context 
of location determination of a specific IP client device 
(with one physical interface) in a wireline network, an 
important piece of information is the location of the first 
managed switch that provides the (layer 2/3) entry point 
into the network. Here, the term "first" refers to the 
phone's perspective, looking toward the network. The 
term "managed" refers to a switch that is maintained as 
part of the managed infrastructure of a local network, e. 


g., by an enterprise's IT department. It is used to distin- 
guish from an unmanaged switch, such as a desktop 
switch that may be connected to the network, but de- 
ployed outside the boundary of the managed inf rastruc- 

s ture. Note that an unmanaged switch may still be dis- 
coverable by the network management system of the 
managed infrastructure, but critical attributes such as lo- 
cation might not be available or reliable. 
[0093] The switch port on the first managed switch 

io provides the most specific location information availa- 
ble, with respect to the managed infrastructure. The in- 
frastructure may be configured to provide a unique 
switch port to individual locations, such as offices or cu- 
bicles. In this case, the identity of the managed switch 

15 port also specifies the location of the managed physical 
connection point. Alternatively, the configuration could 
be set up to provide area-wide, shared access to all or 
some of the managed switch ports, for example, by lo- 
cating managed hubs between the shared switch ports 

20 and available connection points distributed across sev- 
eral offices or cubicles. In this case, the identity of the 
managed switch port specifies only the area served, but 
cannot distinguish between individual connection 
points. The precision of the location in the former case 

25 would likely be greater than that in the latter case 
(though not necessarily). 

[0094] If the first managed switch port is also the first 
port to which a client device is connected (i.e., there are 
no unmanaged switches in between), then it provides 

30 the most specific location information for that client, with 
respect to the managed infrastructure, and with a pre- 
cision corresponding to the sharing configuration of the 
port. For example, If a managed switch port serves a 
single office, then a client device connected to that port 

35 would be known to be connected in the corresponding 
office. Note that this does not preclude the possibility of 
using a very long Ethernet cable for the connection, 
thereby effectively decreasing the precision of the loca- 
tion information. If instead, a managed switch port 

40 serves a cluster of cubicles, then a client device con- 
nected to that switch port would be known to be con- 
nected in one of cubicles in the cluster. Again, non- 
switched extensions (e.g., hubs) could decrease the ef- 
fective precision of the location information. 

45 [0095] If a client device is connected to the first man- 
aged switch port via an unmanaged switch (e.g., an in- 
tervening desktop switch), then the precision of the lo- 
cation of the client with respect to the managed infra- 
structure is effectively decreased, in a similar mannerto 

so a non-switched extension. However, there are two po- 
tential differences: 1) the network management system 
214 may be able to detect the presence of the unman- 
aged switch; and 2) such a switch could provide unman- 
aged bridging of multiple subnets, which could be prob- 

55 lematic from the point of view of client location determi- 
nation (particularly if the client device has more than one 
physical interface). As is discussed in the next subsec- 
tion , management of switch ports may include the ability 
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to discover unman aged switches, and detect if they in- 
troduce any problematic topologies. 

2. Switch Port Management 

[0096] Switch port management refers to establishing 
and maintaining identifying information about the man- 
aged switch ports that are configured for first-port ac- 
cess for client devices. This information should be suf- 
ficient to specify the location of a connected client, at 
least to the precision supported by the port-sharing con- 
figuration. 

[0097] When a network is set up, a new switch in- 
stalled, or an existing switch relocated, this information 
must be updated. Assuming that the network manage- 
ment system 214 can discover the network topology, 
any updates to the location information must be validat- 
ed against the port-to-port and/or switch-to-switch con- 
nections determined by the topology. This is discussed 
in the previous section under "System Configuration." 
[0098] Switch port management also includes discov- 
ery of unmanaged switches, if possible. While location 
information for such devices may not be reliable, their 
presence in the path between client devices and man- 
aged switches may be detectable. Further, any unman- 
aged switch that provides bridging between managed 
switch ports or between IP subnets must be flagged, if 
the bridging topology can be discovered. If such an un- 
managed switch is determined to be the first switch port 
connection for an IP calling station (SIP phone), then an 
alert can be generated to the network management sys- 
tem 21 4, allowing appropriate action to be taken accord- 
ing to local policy. 

[0099] The identifying information in a switch config- 
ured to provide first switch port access could include: 
the IP address of the switch; the Port number on the 
switch; the Switch location; the most precise location as- 
sociated with port number (e.g., office, cubicle, cluster, 
floor, etc.); managed physical connection points as- 
signed to the switch port. 

3. Automatic Discovery 

[01 00] Automatic discovery encompasses three proc- 
esses: 

1 . Discovery of network topology, including man- 
aged and unmanaged switches (if possible); 

2. Discovery of calling stations (SIP phones); and 

3. Generation and population of the Location Server 
database. 

The first process is generally a capability pro- 
vided by the network management system 214. 
Suitable network management tools and features 
are available on platforms such as HP Openview, 
available from Hewlett Packard. Alternatively, new 
software layers (e.g., middleware) may be used to 
provide this service to the Location server via an 


API, or similar programmable interface. The soft- 
ware preferably utilizes the SNMP protocol to obtain 
routing tables from routers and bridging tables from 
switches to identify an IP address with a known port 

s and physical location. 

Processes (2) and (3) preferably run on the Lo- 
cation server. They access the interface to the net- 
workman agement system 21 4 as needed. For each 
calling station, the second process combines the 

10 switch port identification information with any loca- 
tion information that may be supplied by the calling 
station, in order to determine the most accurate lo- 
cation of the calling station, as well as its ERL. It is 
possible for the result this process to indicate an in- 

15 consistency in the one or more of the reported con- 
figurations. For example, if the physical mapping of 
switch ports to physical connections is modified, but 
the change is not properly updated in the provision- 
ing system, then the NMS discovery could disagree 

20 with the recorded mappings. If the change is made 
while registered SIP phones are connected to the 
switch, then the phones' internally stored location 
information will disagree with that reported from an 
NMS discovery procedure. 

25 The respective weightings given to the phone 

location information and the switch port location in- 
formation depends upon the trigger that invokes the 
discovery process. For example, if a SIP registra- 
tion is the trigger, then the switch port information 

,30 is taken as correct. However, if periodic verification 
check is the trigger, and the phone has maintained 
continuous registration, then the phone location 
may be selected overthat of the switch port (assum- 
ing disagreement). 

35 The third process uses input from the second 

process to generate the Location Server database 
records. 

4. Triggers and Actions 

40 [0101] Triggers are the events that cause the auto- 
matic discovery processes to run. Actions are additional 
tasks and/orfunctions that are associated with process- 
es. The trigger for process (1 ) is a request for informa- 
tion from either of the othertwo processes. That is, when 

45 either process of (2) or (3) executes, they invoke proc- 
ess (1 ) in orderto get the required input. It is up to proc- 
ess (1) to decide how to carry out the request. For ex- 
ample, whether restricted or full topology discovery is 
required to fulfill the request; or whether current topo lo- 

so gy information is applicable to a request, without actually 
running any discovery steps. 

[0102] The triggers for process (2) are: SIP phone 
registration; Periodic, automatic verification check. 
[0103] The triggers for process (3) are: System turn- 
55 up; SIP phone registration; Periodic, automatic verifica- 
tion check. 
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Claims 

1 . A method of configuring a packet based phone for 
initiating an emergency call in a packet based net- 
work, comprising: 

receiving an ERL record at a packet based 
phone, said ERL record being associated with 
the phone's emergency response location; and 
transmitting from the packet-based phone at 
least a portion of the ERL record as part of an 
emergency call setup process. 

2. The method of claim 1 , wherein the packet based 
network is an Internet Protocol network. 

3. The method of claim 1 , wherein the ERL record in- 
cludes one or more ELINs, and wherein the phone 
transmits at least one of the ELINs. 

4. The method of claim 1 , wherein the ERL record in- 
cludes one or more ELINs, and wherein the phone 
transmits at least one of the ELINs using the Ses- 
sion Initiation Protocol. 

5. The method of claim 1 , wherein the packet-based 
phone uses the Session initiation Protocol. 

6. The method of claim 1 , wherein the ERL record in- 
cludes one or more ELINs, and wherein the phone 
transmits at least one of the ELINs in an SDP con- 
tained in a SIP INVITE message. 

7. The method of claim 1 , wherein the phone transmits 
at least a portion of the ERL record to a PSTN gate- 
way device. 

8. The method of claim 7, wherein the phone selects 
the PSTN gateway device according information in 
the ERL record. 

9. The method of claim 7, wherein the portion of the 
ERL record comprises an ERL ID, and the PSTN 
gateway device inserts a corresponding ELIN into 
the caller identification portion of an outgoing emer- 
gency services call. 

10. The method of claim 7, wherein the portion of the 
ERL record comprises one or more ELINs, and the 
PSTN gateway device inserts one of the ELINs into 
the caller identification portion of an outgoing emer- 
gency services call. 

11. The method of claim 7, wherein the PSTN gateway 
device maintains a list of ELINs associated with a 
caller identification portion of active outgoing emer- 
gency services calls, and wherein the PSTN gate- 
way device selects ELINs for new outgoing emer- 


gency services calls. 

1 2. The method of claim 1 , wherein the phone transmits 
at least a portion of the ERL record to a call signaling 

5 device. 

13. The method of claim 12, wherein the portion of the 
ERL record comprises at least an ERL ID, and the 
call signaling device selects a corresponding ELIN. 

10 

14. The method of claim 13, wherein the signaling de- 
vice transmits a requestto a PSTN gateway to make 
an outgoing emergency services call using an ELIN 
inserted into a caller identification portion of the out- 

15 going call. 

15. The method of claim 12, wherein the portion of the 
ERL record comprises one or more ELINs, and the 
call signaling device selects an ELIN. 

20 

16. The method of claim 15, wherein the signaling de- 
vice transmits a requestto a PSTN gateway to make 
an outgoing emergency services call using an ELIN 
inserted into a caller identification portion of the out- 

25 going call. 

17. The method of claim 12, wherein the call signaling 
device maintains a list of ELINs assigned to a caller 
identification portion of active outgoing emergency 

30 services calls, and wherein the call signaling device 
selects ELINs for new outgoing emergency services 
calls. 

18. The method of claim 12, wherein the call signaling 
35 device is a SIP Proxy server. 

19. The method of claim 12, wherein the requestto the 
PSTN gateway is a SIP INVITE message. 

40 20. The method of claim 1 further comprising the step 
of determining the emergency response location of 
the phone based in part on an IP address of the 
phone. 

45 21. The method of claim 1 further comprising the step 
of determining the emergency response location of 
the phone based in part on a MAC address of the 
phone. 

so 22. The method of claim 1 further comprising the step 
of determining the emergency response location of 
the phone based in part on a serial number of the 
phone. 

55 23. The method of claim 1 , further comprising the step 
of transmitting an address of a PSTN gateway de- 
vice for use during an emergency call. 
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24. The method of claim 1 , further comprising transmit- 
ting a first notification message to a monitoring sta- 
tion when an emergency call is placed by a phone. 

25. The method of claim 24, wherein the monitoring sta- 
tion ensures that a corresponding notification mes- 
sage is received from a PSTN gateway. 

26. The method of claim 25, wherein the monitoring sta- 
tion issues an alarm if it fails to receive the first no- 
tification message from the phone and the corre- 
sponding notification message from the PSTN gate- 
way. 

27. The method of claim 25, wherein a SIP NOTIFY 
message is used to send the notification from the 
PSTN gateway to the monitoring station. 

28. The method of claim 24, wherein a SIP NOTIFY 
message is used to send the notification from the 
phone to the monitoring station. 

29. A method of configuring a packet based phone for 
initiating an emergency call in a packet based net- 
work, comprising: 

determining an ERL of the packet based phone; 
and 

transmitting a corresponding ERL record to the 
packet based phone, said ERL record including 
parameters enabling the packet based phone 
to initiate an emergency services call. 

30. The method of claim 29, wherein the packet based 
network is an Internet Protocol network. 

31 . The method of claim 29, wherein the packet based 
phone uses SIP. 

32. The method of claim 29, wherein the ERL record is 
transmitted to the packet based phone using SIP. 

33. The method of claim 29, wherein the ERL record is 
transmitted to the packet based phone using a SIP 
OK message, issued in response to a SIP REGIS- 
TER message from the packet based phone to a 
SIP network. 

34. The method of claim 29, wherein the ERL record is 
transmitted to the packet based phone as a textual 
message in the body of a SIP OK message, issued 
in response to a SIP REGISTER message from the 
packet based phone to a SIP network. 

35. The method of claim 29, wherein the step of deter- 
mining an ERL further comprises receiving an IP 
address of the phone, and determining the ERL in 
response to the received IP address. 


36. The method of claim 35, wherein the step of deter- 
mining the ERL in response to the received IP ad- 
dress comprises querying a network management 
system. 

5 

37. The method of claim 29, wherein the step of deter- 
mining an ERL further comprises receiving a MAC 
address of the phone, and determining the ERL in 
response to the received MAC address. . 

10 

38. The method of claim 37, wherein determining the 
ERL in response to the received MAC address com- 
prises querying a network management system. 

15 39. The method of claim 29, wherein the step of deter- 
mining an ERL further comprises receiving a serial 
number of the phone, and determining the ERL in 
response to the received serial number. 

20 40. The method of claim 39, wherein determining the 
ERL in response to the received serial number com- 
prises querying a network management system. 

41. A method of configuring a packet based phone for 
25 initiating an emergency call in a packet based net- 
work, comprising: 

receiving an ERL record at a packet based 
phone, the ERL record containing at least one 
so ormore ELINs and address information for con- 

tacting one or more emergency PSTN gate- 
ways; 

responsively storing at least the information in 
the ERL record required to initiate an emergen- 
35 cy services call. 

42. The method of claim 41 wherein the packet based 
network is an internet Protocol network. 

40 43. The method of claim 41 , wherein the packet based 
phone uses SIP. 

44. The method of claim 41 , wherein the ERL record is 
received at the phone using SIP 

45 

45. The method of claim 41 , wherein the ERL record is 
received at the phone using a SIP OK message, re- 
ceived in response to a SIP REGISTER message 
from the packet based phone to a SIP network. 

50 

46. The method of claim 41 , wherein the ERL record is 
received at the phone as a textual message in the 
body of a SIP OK message, issued in response to 
a SI P REGISTER message from the phone to a SI P 

55 network. 

47. The method of claim 41 , further comprising the step 
of deregistering a user profile with a SIP proxy in 
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the event a user dials an emergency sen/ices 
number. 

48. The method of claim 41 , wherein, responsive to the 
event of the packet based phone receiving signaling 
for an incoming call while an emergency services 
call placed by the phone is still active, preventing 
the incoming call from interrupting the active emer- 
gency services call. 

49. The method of claim 41 , wherein, responsive to the 
event of the user attempting to disconnect an emer- 
gency services call, declining to issue the requisite 
disconnect signaling, and instead entering speaker 
phone mode. 

50. A method of configuring a packet based phone for 
initiating an emergency call in a packet based net- 
work, comprising: 

establishing a plurality of ERL records, each of 
the ERL records containing at least the follow- 
ing information: ERL ID; textual location de- 
scription; managed network connection points 
associated with the ERL; ELlNs associated 
with the ERL; PSTN gateways associated with 
the ERL; 

establishing a plurality of phone location infor- 
mation records, each of the phone location 
records containing at least the following infor- 
mation: a IP address of the phone; a MAC ad- 
dress of the phone; a serial number of the 
phone; an ERL ID associated with the phone; 
a managed network connection point associat- 
ed with the phone; an ELiN associated with the 
phone; one or more PSTN gateways associat- 
ed with the phone; and 

transmitting to a phone at least part of the ERL 
record including parameters enabling the pack- 
et based phone to initiate an emergency serv- 
ices call. 

51 . The method of claim 50, wherein the packet based 
network is an Internet Protocol network. 

52. The method of claim 50, wherein the packet based 
phone uses SIP. 

53. The method of claim 50, wherein the plurality of ERL 
records is maintained in a centralized database. 

54. The method of claim 50, wherein the plurality of 
phone location information records is maintained in 
a centralized database. 

55. The method of claim 50, wherein the at least part of 
the ERL record transmitted to the packet based 
phone is identified according to the managed net- 


work connection point of the phone. 

56. The method of claim 55, wherein the managed net- 
work connection point of the phone is determined 

5 by querying a network management system with the 
IP address of the packet based phone. 

57. The method of claim 55, wherein the managed net- 
work connection point of the phone is determined 

10 by querying a network management system with the 
MAC address of the packet based phone. 

58. The method of claim 55, wherein the managed net- 
work connection point of the phone is determined 

15 by querying a network management system with the 
serial number of the packet based phone. 

59. The method of claim 50, wherein the at least part of 
the ERL record is transmitted to a packet based 

20 phone responsive to a request containing the IP ad- 
dress of the packet based phone. 

,60. The method of claim 50, wherein the at least part of 
the ERL record is transmitted to a packet based 
25 phone responsive to a request containing the MAC 
address of the packet based phone. 

61 . The method of claim 50, wherein the at least part of 
the ERL record is transmitted to a phone responsive 

30 to a request containing the serial number of the 
packet based phone. 

62. The method of claim 50, wherein each of the plural- 
ity of phone location Information records is assoei- 

35 ated with a distinct packet based phone, each of the 
distinct packet based phones being connected to 
the network at a managed network connection 
point. 

40 63. The method of claim 50, further comprising the 
steps of: 

receiving a registration request containing 
identifying information of a packet based 

45 phone; 

determining that a corresponding phone loca- 
tion information record for the packet based 
phone does not exist; and 
creating a new phone location information 

so record. 

64. The method of claim 63, wherein the identifying in- 
formation comprises an IP address. 

55 65. The method of claim 63, wherein the identifying in- 
formation comprises a MAC address. 

66. The method of claim 63, wherein the identifying in- 
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formation comprises a serial number. 

67. The method of claim 50, further comprising the step 
of verifying the accuracy of each of the plurality of 
phone location information records. 5 

68. The method of claim 67 wherein the accuracy is ver- 
ified by the steps of: 

sending a network management query request- io 
ing the identity of the managed network con- 
nection point of the individual phone using one 
of the IP address and the MAC address of the 
. phone, as stored in the associated phone loca- 
tion information record, and receiving a network « 
management query response; 
sending a phone query to the packet based 
phone requesting its stored ERL record, and re- 
ceiving a phone query response; 
comparing the managed network connection 20 
point reported in the network management que- 
ry response with the identity of the managed 
network connection point reported in the phone 
query response; 

comparing the identity of the managed network 25 
connection point reported in the network man- 
agement query response with the identity of the 
managed network connection point reported in 
the phone query response; and 
comparing the identity of the managed network so 
connection point reported in the phone query 
response with the identity of the managed net- 
work connection point reported in the network 
management query response; 
issu ing a software alert if one of the above com- 35 
parisons are not the same, 

69. The method of claim 68 further comprising a pro- 
grammable schedule upon which the said sequen- 
tial steps are initiated for each existing individual *o 
phone location information record. 


45 
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